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(54) Multithread data processor 

(57) An apparatus for processing digital audio-vis- 
ual data, in particular a receiver/decoder for a digital tel- 
evision system, comprising one or more hardware 
devices for transmission and reception of data, the 
hardware devices having at least one associated hard- 
ware operating system 4100, the decoder further com- 
prising a data processing system including a multi- 
thread virtual machine 4250 adapted to, inter alia, 
receive event messages signalled by the hardware 
operating system and to assign corresponding event 
objects 4564 to one or more threads 4561 , and in which 
a thread including an event object may be suspended 
during the course of its execution to permit the execu- 
tion of another thread. 
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Description 

[0001] The present invention relates to an apparatus 
for processing digital audio-visual data, in particular a 
decoder for a digital television system including a multi- 
thread data processor. 

[0002] A software based system for controlling a 
decoder in a digital television system that uses a virtual 
machine and run time engine for processing digital tele- 
vision data and downloaded applications is described in 
the PCT application PCT/EP97/021 16. This system 
possesses a number of advantages in comparison with 
previously known systems for receiver/decoders, nota- 
bly in regard to the independence of the application lay- 
ers of the system to the hardware elements of the 
manufactured decoder through the use of a virtual 
machine structure. 

[0003] The system described in this application uses 
the principle of a single file queue-based structure for 
controlling and processing events that arise in the sys- 
tem. A number of disadvantages are associated with a 
queue based structure, including a relatively slow 
response to high priority events and an inability to effi- 
ciently handle a number of concurrent inputs into the 
system. As described, the system includes a number of 
process sequencer units. Although the system can pri- 
oritise the operation of such sequencers, once a partic- 
ular process is started, it is not possible to change to 
another. 

[0004] These drawbacks of the structure become par- 
ticularly acute in the case where the receiver/decoder 
includes an interactive application. For example, the 
inability of the system to change tasks in response to a 
priority command combined with the often lengthy time 
needed to download data can result in the system being 
locked into one operation despite commands from the 
user to change to another mode. 
[0005] There is also a need to simplify the device 
driver structure of this known system. Communication 
between the run time engine and the hardware levels of 
the known decoder is handled by a plurality of device 
drivers, the overall organisation of which is handled by a 
device manager which manages the prioritisation of 
event messages and their input into the queue structure 
of the process sequencer units. As discussed in the 
application, whilst the run time engine is provided by the 
system authority, the device drivers and manager are 
usually provided by the decoder manufacturer, following 
the specifications of the system authority. 
[0006] Differences in interpretation of the specification 
by the decoder manufacturer can lead to problems 
where, for example, the manager does not respect the 
correct classification of priority events. In such a case, 
the queuing system will be disrupted as the events sup- 
plied to the event filter and process sequencer will be 
wrongly identified in terms of their priority and will be 
incorrectly handled by the queuing system. 
[0007] It is an object of the present invention in its 
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broadest and preferrd^^pects to overcome these 
problems of the prior art system. 
[0008] According to the present invention, there is pro- 
vided an apparatus for processing digital audio-visual 

5 data comprising one or more hardware devices for 
transmission and reception of data, the hardware 
devices having at least one associated hardware oper- 
ating system, the apparatus further comprising a data 
processing system including a multi-thread virtual 

10 machine adapted to, inter alia, receive event messages 
signalled by the hardware operating system and to 
assign corresponding event objects to one or more 
threads, and in which a thread including an event object 
may be suspended during the course of its execution to 

75 permit the execution of another thread. 

[0009] Through the use of a multithread architecture, 
the present invention thus enables the system to 
respond effectively to the arrival of events received via 
the external interfaces of the device, allowing rapid 

20 treatment of high priority events during the temporary 
suspension of non-urgent processes. 
[0010] In one embodiment, the virtual machine has a 
pre-emptive multithread architecture, in which a thread 
is suspended during the course of its execution upon 

25 the creation of a thread of higher priority. Whilst this 
embodiment is preferred for its responsiveness to prior- 
ity events, other embodiments may be envisaged, such 
as a time-slice embodiment, in which the virtual 
machine interrupts execution of a thread at pre-deter- 

30 mined periodic intervals to see if another thread to be 
executed exists. 

[0011] Preferably, the virtual machine comprises an 
event manager adapted to respond to an event mes- 
sage signalled by the hardware operating system by 

35 storing an event object in one or more threads in a pri- 
ority organised thread queue. 
[0012] In this way, the prioritisation of events can be 
handled directly by the virtual machine, avoiding the 
problems of the known system, in which events are first 

40 ordered for insertion in the processor queue by low level 
device drivers and managers. As discussed above, the 
implementation of a driver may be variable from one 
manufacturer to another. In contrast, in this preferred 
embodiment, event messages are sorted and prioritised 

45 by an event manager within the virtual machine, the 
characteristics of which are unchangeable from one 
platform to another. 

[001 3] Notwithstanding the fact that event handling is 
now effectively carried out by the virtual machine, the 

so system may nevertheless also comprise in certain 
embodiments one or more device drivers to serve as an. 
interface between the operating system of the virtual 
machine and the hardware level operating system. 
[0014] In addition to events arising from the hardware 

55 operating system, the event manager may also be con- 
figured to respond to event messages arising from 
within the virtual machine or from higher level applica- 
tions. 
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[0015] In preferred embojJ^its, the order of event 
objects within a thread may also be prioritised according 
to the priority of the event and/or the arrival time of the 
event. This may be in addition to the initial prioritisation 
carried out in the assignment of instructions to threads 5 
in the thread queue. 

[0016] In one implementation, the virtual machine may 
also comprise a routing table containing information 
regarding possible event messages and addressable by 
the event manager to enable the event manager to 10 
determine the thread correspondence of a received 
event message. This routing table may also be used to 
determine the priority of an event object within a thread. 
As will be understood by one skilled in the art, alterna- 
tive means may also be used. is 
[0017] In addition to an event manager and routing 
table, the virtual machine also preferably comprises a 
scheduler adapted to examine the threads held in the 
priority organised thread queue and to command the 
execution of the thread having the highest priority at that 20 
time. In order to implement a pre-emptive thread man- 
agement operation, the event manager may be adapted 
to signal the arrival of an event message and to cause 
the scheduler to examine the new state of the threads 
held in the thread queue. 25 
[0018] Whilst the present invention is particularly 
applicable to a decoder for receiving and processing 
digital television systems, it will be understood that the 
principles of the data processing system set out in this 
application may also be applied to other devices for 30 
handling digital audio-visual data, such as digital video 
recorders and the like. In the context of a decoder for a 
digital television broadcast, the hardware devices of the 
decoder can include an MPEG demultiplexer together 
with a tuner, a serial interface, a parallel interface, a 35 
modem and one or more smart card readers. 
[0019] In the present application, the term "decoder" 
is used to apply to an integrated receiver/decoder for 
receiving and decrypting an encoded broadcast, the 
receiver and decoder elements of such a system as 40 
considered separately, as well as to a digital television 
receiver for receiving non-encrypted broadcasts. 
[0020] There will now be described, by way of exam- 
ple only, an embodiment of the present invention, with 
reference to the attached figures, in which: 45 

Figure 1 shows an overall view of a digital television 
system; 

Figure 2 shows the elements of an interactive sys- so 
tern within the digital television system of Figure 1 ; 

Figure 3 shows the architecture of the software 
based system implemented within the 
receiver/decoder of the present invention; 55 

Figure 4 shows the architecture of the virtual 
machine within the system of Figure 3, including in 



particular an event manager package, an interpre- 
tation package and a memory package; 

Figure 5 shows the structure of the interpreter used 
in the virtual machine; 

Figure 6 shows the thread handling within the vir- 
tual machine; 

Figure 7 shows the operation of the event manager 
and scheduler of the virtual machine; 

Figure 8 shows the management of the memory 
pool by the virtual machine. 

DIGITAL TELEVISION NETWORK 

[0021 ] An overview of a digital television system 1000 
according to the present invention is shown in Figure 1 . 
The invention includes a mostly conventional digital tel- 
evision system 2000 that uses the known MPEG-2 com- 
pression system to transmit compressed digital signals. 
In more detail, MPEG-2 compressor 2002 in a broad- 
cast centre receives a digital signal stream (typically a 
stream of video signals). The compressor 2002 is con- 
nected to a multiplexer and scrambler 2004 by linkage 
2006. 

[0022] The multiplexer 2004 receives a plurality of fur- 
ther input signals, assembles one or more transport 
streams and transmits compressed digital signals to a 
transmitter 2008 of the broadcast centre via linkage 
2010, which can of course take a wide variety of forms 
including telecommunications links. The transmitter 
2008 transmits electromagnetic signals via uplink 2012 
towards a satellite transponder 2014, where they are 
electronically processed and broadcast via notional 
downlink 2016 to earth receiver 2018, conventionally in 
the form of a dish owned or rented by the end user. The 
signals received by receiver 2018 are transmitted to an 
integrated receiver/decoder 2020 owned or rented by 
the end user and connected to the end user's television 
set 2022. The receiver/decoder 2020 decodes the com- 
pressed MPEG-2 signal into a television signal for the 
television set 2022. 

[0023] A conditional access system 3000 is connected 
to the multiplexer 2004 and the receiver/decoder 2020, 
and is located partly in the broadcast centre and partly 
in the decoder. It enables the end user to access digital 
television broadcasts from one or more broadcast sup- 
pliers. A smartcard, capable of deciphering messages 
relating to commercial offers (that is, one or several tel- 
evision programmes sold by the broadcast supplier), 
can be inserted into the receiver/decoder 2020. Using 
the decoder 2020 and smartcard, the end user may pur- 
chase commercial offers in either a subscription mode 
or a pay-per-view mode. 
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INTERACTIVE SYSTEM WITHIN THE DIGITAL TELE- 
VISION NETWORK 



[0024] An interactive system 4000, also connected to 
the multiplexer 2004 and the receiver/decoder 2020 and 5 
again located partly in the broadcast centre and partly 
in the decoder, enables the end user to interact with var- 
ious applications via a modemmed back channel 4002. 
[0025] Figure 2 shows elements of the general archi- 
tecture of the interactive television system 4000 com- 10 
prising in overview four main elements: 

1 . An authoring tool 4004 at the broadcast centre or 
elsewhere for enabling a broadcast supplier to cre- 
ate, develop, debug and test applications. is 

2. An application and data server 4006, at the 
broadcast centre, connected to the authoring tool 
4004 for enabling a broadcast supplier to prepare, 
authenticate and format applications and data for 20 
delivery to the multiplexer and scrambler 2004 for 
insertion into the MPEG-2 transport stream (typi- 
cally the private section thereof) to be broadcast to 

the end user 

25 

3. A data processing system 4008 at the 
receiver/decoder for receiving and processing 
downloaded applications and data and for manag- 
ing communication with the other elements of the 
interactive system and the hardware elements of 30 
the receiver/decoder, the system 4008 including a 
virtual machine with a run time engine (RTE) imple- 
mented as executable code installed in the 
receiver/decoder. 

35 

4. A modemmed back channel 4002 between the 
receiver/decoder 2020 and the application and data 
server 4006 to communicate signals instructing the 
server 4006 to insert data and applications into the 
MPEG-2 transport stream at the request of the end 40 
user. Information may also be passed in the other 
direction. 

[0026] The receiver/decoder 2020 includes a number 
of devices for communicating with exterior devices 45 
within the interactive system, such as an tuner for tuning 
the receiver, an MPEG demultiplexer for demultiplexing 
the MPEG signal, a serial interface, a parallel interface, 
a modem and one or two card readers adapted to read, 
for example, credit cards or subscription smart cards so 
issued with the system. The characteristics of such 
devices are well known in the field of digital television 
systems and will not be described here in any more 
detail. 

[0027] Similarly the sorts of interactive applications 55 
that may be provided (home banking, teleshopping, 
downloading of computer software) will be apparent to 
those in the field and will not be described in more 
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detail. While the decod^^stem architecture described 
below is particularly apt for interactive applications it will 
also be appreciated that the architecture described can 
be used in simpler non-interactive digital TV systems, 
such as a conventional pay TV system. 



DECODER SYSTEM ARCHITECTURE 

[0028] Turning now to the architecture of the system 
within the receiver/decoder shown in Figure 3, it will be 
seen that a layered architecture is used. The first layer 
4100 represents the operating system of the hardware 
of the receiver/decoder. This is a real-time operating 
system chosen by the manufacturer to control the hard- 
ware elements of the receiver/decoder. The real-time 
operating system has a relatively fast response time in 
order to be able to correctly synchronise hardware oper- 
ations. Event messages are passed between this layer 
and the middleware layer 4200 immediately above. 
[0029] The data processing system 4008 sits on top of 
the hardware operating system and comprises a mid- 
dleware layer and an application (or more correctly an 
application interface) layer. 

[0030] The middleware layer is written in a language 
such as C ANSI and comprises the elements of a virtual 
machine 4250 and a number of interfaces 4260 includ- 
ing a graphical interface 4261, a FLASH/PROM mem- 
ory interface 4262, a protocol interface 4263 and a 
device interface 4264. 

[0031 ] As with the system set out in patent application 
PCT/EP97/021 16 described in more detail in the intro- 
duction, the present invention uses a virtual machine in 
order to provide independence between upper level 
applications and the lower level operating system imple- 
mented by the manufacturer. 

[0032] The interfaces 4260 provide the link between 
operations of the virtual machine and the lower level 
operating system 4100 and also include a number of 
intermediate level application modules more easily exe- 
cuted at this level. 

[0033] The application interface (API) layer 4300 com- 
prises a number of high level packages 4310-4314, writ- 
ten in an object-oriented interpretative language, such 
as Java. These packages provide an interface between 
the applications created by the service provider (inter- 
active program guide, teleshopping, internet browser 
etc) and the virtual machine of the system. Examples of 
such applications are given below. 
[0034] The lower level OS is normally embedded in 
the hardware components of the decoder, although in 
some realisations, the lower level OS can be - down- 
loaded. The middleware and application interface layer 
packages can be downloaded into the RAM or FLASH 
memory of the decoder from a broadcast transmission. 
Alternatively, some of all of the middleware or applica- 
tion interface layer elements can be stored in the ROM 
or (if present) FLASH memory of the decoder. As will be 
understood, the physical organisation of the memory 
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elements of the decoder i^fctinct from the logical 
organisation of the memory. 

APPLICATION INTERFACE LAYER 

5 

[0035] Referring to the application interface layer 4300 
shown in Figure 3, and as described above, the pack- 
ages in this layer are written in an object oriented lan- 
guage such as Java. Each package defines a set of 
class libraries called on during operation of the system. 10 
In the present system the following packages are 
installed. 

[0036] Lang/Util Package 4310. These packages 
define the classes necessary for the manipulation of 
objects by the virtual machine. These class libraries is 
normally form part of a standard library associated with 
the object oriented language chosen. 
[0037] MHEG-5 Package 431 1 . This package defines 
the classes associated with the manipulation of graphi- 
cal objects on the television display. Such objects are 20 
distinct from audio-visual data and can make up t for 
example, channel identifiers or text laid over displayed 
images. The definition of classes within this package - 
should respect the MHEG-5 norms defined by the 
standards ETS 300777-3 and ISO/ISE 13522-5 (and 25 
the standard ISO/ISE 13522-6 in the case of a Java 
implemented system). 

[0038] Toolbox Package 4312. This package contains 
the classes used for downloading and decompression 
of information as well as the classes associated with the 30 
management of the file system and memory within the 
receiver/decoder and the classes associated with the 
connection to the internet etc. 
[0039] Device Package 4313. This package defines 
the classes necessary for management of peripherals 35 
attached to the receiver/decoder, as discussed above 
and including the modem, the smart card readers, the 
MPEG flow tuner etc 

[0040] Service Package 4314. This package defines 
the classes necessary for the implementation of devel- 40 
oping higher level interactive applications, such as man- 
agement of credit card data etc. 
[0041] DSMCC-UU Package 4315. This package 
implements the protocols necessary for communication 
between a client and a server for data file search and 45 
reading. Implementation of this package should respect 
the norm ISO/IEC 13818-6 and directives defined in 
DAVICpart9. 

[0042] A further layer of interactive applications, writ- 
ten by the service provider and downloaded during so 
broadcast as in conventional systems, will be laid over 
the interface packages defined above. Depending on 
the applications to be introduced, some of the above 
packages may be omitted. For example, if the service 
provider does not intend to provide a common way for ss 
data reading, the DSMCC-UU package may be left out 
of the final system. 

[0043] The packages 4300 provide class libraries for 




an object-oriented programming environment. Their 
class behaviour will depend on the language chosen. In 
the case of a Java application, for example, a single 
inheritance class structure will be adhered to. 

INTERFACE LAYER 

[0044] As shown, the interface layer is composed of 
four modules, a graphics module 4261. a memory file 
management module 4261, a protocol module 4263 
and a device manager 4264. Whilst the modules at this 
level are described as interface modules their function is 
to provide a "glue" layer for the implementation of the 
application interface packages and for the operation of 
the virtual machine generally. 

[0045] The graphics module;4261, for example, pro- 
vides the creation and management of graphical 
objects. It asks the low level OS to display basic graphic 
shapes such as single pixels, lines, rectangles etc. The 
implementation of this module depends on the graphics 
capability of the low level manufacturer's OS. In some 
ways complementary to the MHEG-5 package 4311, 
these functions may be more efficiently executed at this 
code level than in the high level code chosen for the 
application layer above. 

[0046] In a similar manner, the memory file manage- 
ment module 4262 includes low level read/write file 
commands associated with the memory components of 
the system. Typically, the hardware operating system 
only includes commands necessary to read/write a sec- 
tor or page within a memory component. As with the 
graphics module 4261, this module enables a set of 
simpler lower level applications to be efficiently intro- 
duced in the system. 

[0047] The protocol management module 4263 
defines a library of communication protocols that may 
be called upon in communications via, for example, the 
TCP/IP layer of the decoder. 

[0048] The device manager 4264 is slightly different 
from the other modules in this layer in that it provides 
the link or interface between the hardware operating 
system and the layers above, including the other mod- 
ules in the interface layer and the virtual machine. Com- 
mands or event messages that are received/sent to the 
hardware OS from the virtual machine, for example, are 
necessarily passed by the device manager for conver- 
sion according to the interface specifications between 
the two levels. 

VIRTUAL MACHINE DESCRIPTION 

[0049] Referring now to Figure 4, the structure of the 
virtual machine 4250 used in the system of the present 
invention will be described. The virtual machine used in 
the present invention is a pre-emptive multithread type 
machine. The general characteristics of such a machine 
are known in other contexts outside of the audio-visual 
and digital television fields and the following description 
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will focus on those areas that are the most specific to 
the present application. 

[0050] The virtual machine is composed of a number 
of elements, which interact broadly as shown in Figure 
4. 

[0051] The scheduler 4270 composed of a thread 
manager service 4271 and a monitor manager service 
4272 forms the heart of the multithread machine. The 
scheduler 4270 orders the execution of threads created 
by applications externally of the virtual machine and 
those created by the virtual machine itself (e.g. a gar- 
bage collection thread as discussed below). 
[0052] The event manager 4273 handles an event 
routing table and the lists of events subscribed to by the 
threads and centralises the dispatch of event treat- 
ments. 

[0053] The memory manager 4274 handles the allo- 
cation and disallocation of the memory zones within the 
system memory and also handles the removal from the 
memory of non-referenced objects (garbage collection). 
[0054] The class manager 4275 charges the classes 
of the application code downloaded in a broadcast sig- 
nal, interacting with the security manager 4280 to check 
the integrity of downloaded code and with the file man- 
ager 4276, which implements the applications. 
[0055] The file manager 4276 carries out the imple- 
mentation of the system files and the handles the mech- 
anism of downloading of interactive applications and 
data. 

[0056] The security manager 4280 handles the level 
of access permitted to downloaded applications, some 
applications having the ability to carry out more opera- 
tions than others in relation to the file system. 
[0057] The interpreter 4277 comprising a bytecode 
interpretation service 4278 and a "m-code" interpreta- 
tion service 4279 handles the interpretation of applica- 
tions written in these two codes, bytecode being 
associated with Java applications and m-code being the 
name given to a proprietary code developed by the 
applicants. As will be discussed, further interpretation 
services can be added if desired. 
[0058] The operation and implementation of the class 
manager, file manager and security manager may be 
conventional. The description will now focus on the 
operation of the interpreter, the scheduler and event 
manager and the memory manager. 

INTERPRETER 

[0059] Referring now to Figure 5, the operation of the 
interpreter 4277 used in the embodiment of the present 
invention will now be described. As discussed in the 
introduction, the disadvantage of conventional operat- 
ing systems used in decoders proposed to date has 
been their reliance on a single type of code for the high 
level applications. Although the code chosen may be a 
commercially available and widely known application 
code, problems can nevertheless arise in the case 



where it is necessary tt^^ntain a field of a number of 
decoders using different applications written in a 
number of codes. The interpreter of the present system 
permits the interpretation of a number of types of code. 

5 [0060] As shown, files arriving in the system, whether 
bytecode classes or m-code modules are evaluated by 
the module class manager 4500 according to the struc- 
ture of the file, such that the application code delivered 
to the interpreter 451 0 has an indication of format. In the 

w case of a bytecode application, for example, the down- 
loaded class file will have a characteristic identification 
header of 4 octets followed by a version number, also of 
4 octets. The interpreter may distinguish between the 
codes on the basis of the presence or absence of this 

is bytecode header. 

[0061 ] In other embodiments, other characteristics of 
the code types may be used to distinguish between any 
number of application languages, such as the file name, 
for example. 

20 [0062] Depending on the result of the format indicator, 
bytecode instructions are sent to the bytecode inter- 
preter 4278, where they are executed with reference to 
a function library 4520 associated with the byte code 
instructions, as is conventionally the case with interpre- 
ts tative code instructions. The function library of native 
code instructions is defined within the virtual machine. 
[0063] In the case of m-code instructions, these are 
passed to a m-code interpreter 4278. The majority of 
the m-code instructions may be implemented and exe- 
30 cuted with reference to the function library 4520 associ- 
ated with byte-code instructions, and the interpreter 
4278 calls on the library 4520 to execute such m-code 
functions wherever possible. 

[0064] In some circumstances, however, some m- 
35 code instructions may need specific execution functions 
not easily executable with reference to a common func- 
tion library. In such cases, it may be envisaged that the 
instructions be implemented with reference to a sepa- 
rate function library 4530. 

40 

SCHEDULER AND EVENT MANAGER 

[0065] The operation of the scheduler 4270 and event 
manager 4273 will now be discussed, with reference to 

45 Figure 6 which shows the life of a thread within the sys- 
tem and Figure 7 which shows the notification of an 
event to a thread by the system in response to an event 
signalled by the lower level run-time operating system. 
[0066] The description will concentrate on the han- 

so dling of the creation of a thread which represents an 
execution context in particular resulting from a signalled 
event. It will be understood that a thread may be created 
with the initiation of a command generated by a higher 
level application to be sent to the hardware OS and by 

55 the return of this command. A thread may also be cre- 
ated within the virtual machine itself, eg a garbage col- 
lection thread. 

[0067] As mentioned above, the present embodiment 
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relies on a pre-emptive threa^fcndling virtual machine 
such as that found in Java based systems. In such a 
machine, a plurality of threads are generated and stored 
in a thread queue. The scheduler inspects the thread 
queue and selects the thread with the highest priority to 
be executed. Normally, the thread that is being executed 
has the highest priority, but such a thread may be inter- 
rupted by a thread of yet a higher priority, as is conven- 
tional in pre-emptive threaded systems. In such a case, 
the state of the interrupted thread is stored and the 
thread re-activated once it reselected to be executed. 
[0068] In certain cases, a thread may itself include a 
so-called "yield" instruction which causes the scheduler 
to suspend the execution of the thread and to inspect 
the thread queue for any other threads to execute. The 
yield instruction may be present in low priority internally 
generated tasks, such as a garbage collection function 
carried out by the system in order to remove unused 
objects from the memory of the system. 
[0069] These aspects of the system are shown in Fig- 
ure 6. The creation of a thread at 4550 gives rise to a 
thread stored in the thread queue 4551. The newly cre- 
ated thread has the state "init" at 4552. If no other 
thread has higher priority, the thread is executed by the 
instruction start() and will have the state "executable" at 
4553. If the instruction stopO is executed in the thread, 
the thread becomes "dead" at 4554. The thread may 
equally achieve this state if completed as indicated by 
the run()fini instruction. If a yieldO instruction in the 
thread itself arises, or a suspendO instruction external 
of the thread is executed, the thread is suspended and 
given the state "non-executable" at 4556. 
[0070] Referring now to Figure 7, the interaction 
between the lower level operating system 4100, the 
event manager 4273 and the scheduler 4270 will now 
be described. Raw events signalled by the run-time 
operating system 4100 are passed via the device man- 
ager 4313 to the event manager 4273. In a preferred 
realisation, some prior itisation of the received events 
may be carried out by the device manager 4313 and/or 
the multitask system used in the operating system 
4100. However, as will become clear, one of the advan- 
tages of the present system lies in the fact that, unlike 
the system described in PCT/EP97/021 16, the handling 
of events is managed within the virtual machine 4250, 
thus enabling creator of the middleware layer to achieve 
complete control over the event handling procedure. 
[0071 ] In the present embodiment, events sent via the 
device manager 4313 are classified by their code and 
their type. The code identifies the characteristics of the 
event, for example, in the case of an event generated 
through operation of a remote control associated with 
the decoder, the code can identify the button 
depressed. The type identifies the origin of the event, 
e.g. the remote control. 

[0072] Upon receipt of an event signal, the event man- 
ager 4273 uses a routing table 4560 to determine the 
event priority and thread destination and inserts a corre- 



094 A1 




sponding event object 4564 into one or more threads 
4561 located within the priority based thread queue 
4562. One or more event objects 4564 mky be stored 
within a given thread as represented at 4563. The event 
5 objects 4564 are stocked within the thread according to 
their priority classification. Event objects within the 
thread of an equal priority are classified by their time of 
arrival (FIFO). 

[0073] Upon receipt of an event, the event manager 

10 4273 signals its arrival to the scheduler 4270, which 
then examines the thread queue to see if a thread has a 
higher priority than the thread currently being executed. 
If so, the current thread is then suspended as described 
above and the new thread executed. In this manner a 

75 pre-emptive thread handling system is implemented. 
[0074] In this way, the preferred embodiment allows 
efficient handling of threads in the decoder so as to per- 
mit the system to respond quickly to event calls, even in 
the case where the system is processing an existing 

20 prior event. The disadvantages of the known single 
processor queue system are thereby overcome. 
[0075] Whilst the preferred embodiment has been 
described in relation to a pre-emptive system in which 
the arrival of an event causes the event manager to sig- 

25 nal the scheduler to interrupt execution of a thread, 
other implementations are possible. For example, in a 
time-slice system, the scheduler can periodically inter- 
rupt execution of a thread to examine the state of the 
thread queue. Alternatively, the scheduler can be 

so adapted to interrupt execution of a thread to examine 
the thread queue after each instruction in that the 
thread is treated. 

MEMORY MANAGER 

35 

[0076] As will be appreciated, in the context of 
receiver/decoder, the management of the memory pool 
within the system is particularly important, since mem- 
ory space is relatively restricted as compared to for 

40 example, a PC or other hard disk based platform. In the 
following description, the memory pool corresponds to 
the memory space within the RAM of the 
receiver/decoder. However, as mentioned above, the 
correspondence between the physical and logical 

45 organisation of the memory is not exact and the mem- 
ory pool described below may be located in or shared 
between other physical memory devices, such as a 
FLASH memory, an EEPROM etc, within the 
receiver/decoder. 

so [0077] Referring now to Figure 8, this shows the 
organisation of the available memory in the system. It 
will be seen that the memory space is shared between 
a pool of handles 4600, a pool of displaceable objects 
4610 and a pool of non-displaceable objects 4620. 

55 [0078] Each object in the pool 4610 is identified by 
and corresponds to a handle stored in the pool 4600. 
The relation between a handle and its corresponding 
object is managed by the memory management pack- 
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age 4274 (see Figure 4) which also controls the access 
to the pool. All calls to objects in the pool are made by 
its handle. The boundary between the pools 4600 and 
4610 is movable. When a new object is to be stored in 
memory a handle is created in the pool 4600 including a 
pointer to the address of the object within the pool 461 0. 
In such a case, the list of handles will be increased by 
one. The handles are organised in a list formation in the 
pool to permit compactage by the memory manager. 
[0079] Objects will be allocated in the pool as needed 
and according to the space available. In the case that an 
object allocation is demanded which requires more 
space in one block than is available, it will be necessary 
to compact the objects already allocated in the memory. 
The compaction of the objects in the memory can be 
carried out according to any known compacting algo- 
rithm, for example, a copy-compact algorithm. In the 
present embodiment, the Mark Sweep compact algo- 
rithm is used. In order to compact space, the objects are 
moved around in the zone 4610, so as to group objects 
more closely together, avoiding any spaces between 
adjacent objects. In this way, all free memory space is 
clustered together in a block so as to allocate for a new 
object in the pool 4610. 

[0080] As mentioned above, the memory manage- 
ment package maintains the correspondence between 
handles in the pool 4600 and objects in the pool 4610 
and the new addresses of the objects in the pool will be 
updated into the equivalent handles for future access. 
[0081] Whilst the use of a handles to access certain 
objects enables the system to optimise memory location 
in the pool, the process increases the time needed to 
access such objects, since it is always necessary to first 
retrieve the handle in order to look up the address of the 
object. In certain situations and for objects correspond- 
ing to certain designated events a more rapid access 
time may be required. 

[0082] In such a case, the objects can be allocated in 
a pool of non-displaceable objects 4620. The address of 
such objects is fixed within the pool. There is thus no 
need for the creation of a handle and the objects are 
used directly by the system, thereby simplifying the 
access procedure for these special objects. Again, as 
with the boundary between the pools 4600 and 4610, 
the boundary between the pools 4620 and 4610 will be 
shifted depending on the information stocked in the pool 
4620. 

[0083] In the event, for example, that a non-displace- 
able object is be allocated to the pool 4620 and there is 
insufficient space due to the arrangement of displacea- 
ble objects in the pool 4610, a compaction of the dis- 
placeable objects may be carried out, as described 
above. Once the objects in the pool are reorganised so 
as to liberate the maximum amount of space it may then 
be possible to allocate a non-displaceable block in the 
pool 4620. 

[0084] The choice of which objects are displaceable 
and which objects are non-displaceable is at the discre- 
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tion of the designer. Fc^™nple, objects correspond- 
ing to the system may becnosen as non-displaceable in 
view of the importance of these objects, whilst high level 
application objects may be displaceable. In certain 
5 instances, displaceable objects can be temporarily 
locked into place so as to be considered as non-mova- 
ble objects. 

[0085] In order to eliminate unwanted objects from the 
memory pool the system may also include a so-called 

w garbage collection. This involves the creation of a spe- 
cial garbage collector thread of the lowest priority which 
will be addressed by the scheduler in the event that no 
other threads are currently stored in the queue. Upon 
execution, all displaceable objects currently allocated in 

15 the pool that are not being referenced at that time will be 
freed. The garbage collector thread may also carry out 
compaction of all other displaceable objects along the 
lines described above. 

[0086] The creation of a garbage collector thread is 
20 known in the context of other multithread systems used 
in other applications outside of a digital television sys- 
tem and will not be discussed in any further detail here. 
However, it will be appreciated that use of a garbage 
collection procedure in combination with the other mem- 
25 ory management techniques described above provides 
particular advantages in the present context. 

Claims 

30 1. An apparatus for processing digital audio-visual 
data comprising one or more hardware devices for 
transmission and reception of data, the hardware 
devices having at least one associated hardware 
operating system, the apparatus further comprising 

35 a data processing system including a multi-thread 
virtual machine adapted to, inter alia, receive event 
messages signalled by the hardware operating sys- 
tem and to assign corresponding event objects to 
one or more threads, and in which a thread may be 

40 suspended during the course of its execution to 
permit the execution of another thread. 

2. An apparatus as claimed in claim 1 in which the vir- 
tual machine has a pre-emptive multithread archi- 

45 tecture, in which a thread is suspended during the 
course of its execution by the creation of a thread of 
higher priority. 

3. An apparatus as claimed in claim 1 or 2, in which 
so the virtual machine comprises an event manager 

adapted to respond to an event message signalled, 
by the hardware operating system by storing an 
event object in one or more threads in a priority 
organised thread queue. 

55 

4. An apparatus as claimed in claim 3, in which event 
messages sent from the hardware operating sys- 
tem to the event manager are first processed by 
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one or more device 



igers within the data 



processing system. 

5. An apparatus as claimed in claim 3 or 4, the event 
manager further being adapted to respond to an s 
event message generated internally by the virtual 
machine or received from a high level application 
within or external of the data processing system. 

6. An apparatus as claimed in any of claims 3 to 5, in 10 
which the event manager classifies event objects 
internally within a thread according to the priority of 
the event message and/or the arrival time of the 
event message. 



7. An apparatus as claimed in any of claims 3 to 6, in 
which the virtual machine further comprises a rout- 
ing table containing information regarding possible 
event messages and addressable by the event 
manager to enable the event manager to determine 20 
the thread correspondence of a received event 
message. 

8. An apparatus as claimed in claim 7 in which the 
routing table contains information to enable the 25 
event manager to determine the priority of an event 
object within a thread. 

9. An apparatus as claimed in any of claims 3 to 8, in 
which the virtual machine further comprises a 30 
scheduler adapted to examine the threads held in 
the priority organised thread queue and to com- 
mand the execution of the thread having the highest 
priority at that time. 



10. An apparatus as claimed in claim 9, in which the 
event manager is adapted to signal the arrival of an 
event message and to cause the scheduler to 
examine the new state of the threads held in the 



11. An apparatus as claimed in any preceding claim in 
which the apparatus is a decoder for a digital televi- 
sion system 



12. An apparatus as claimed in any preceding claim in 
which one of the devices comprises an MPEG 
demultiplexer. 

13. An apparatus as claimed in any preceding claim in 50 
which the hardware devices may comprise at least 
one of the following: a tuner, a serial interface, a 
parallel interface, a modem and one or more smart 
card readers. 
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